home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
graphic
/
xv_pc16a.zip
/
XVIEW_PC.TXT
< prev
next >
Wrap
Text File
|
1994-04-26
|
36KB
|
706 lines
XView-PC: Graphical User Interface for Turbo C and Turbo Pascal
---------------------------------------------------------------
By:
Antonio Carlos Moreirao de Queiroz
Department of Electronic Engineering and COPPE
Federal University of Rio de Janeiro, Brazil
e-mail: acmq@coe.ufrj.br
INTRODUCTION
------------
The XView-PC graphical user interface attempts to be similar to the XView
toolkit used in Sun workstations, in a simplified from.
It can be used in Pascal, C, or C++ versions. The interface is the same in
any of the versions, with minor differences in the Pascal version.
The interface was initially developed as an intermediate step in porting
programs from the PC to Sun workstations, by implementing a subset of the
Sun XView toolkit in the PC. The work was not completed because it soon
become clear that a total translation would be unnecessarily complex. Even
so, the working of the two interfaces was kept similar when reasonable.
What can be done with the interface in its present form can be repeated
with the Sun XView without significant structural changes, although with
differences due to the various simplifications made. The porting of an
application to Windows is also not complex.
The interface code is of simple use and adds only about 25 k to the
executable program doing all the user interface functions. It works with any
PC compatible computer, in any graphics mode supported by the BGI drivers and
installed mouse driver. If a mouse is not installed, a mouse emulator using
the keyboard is automatically used.
To simplify the interface code generation, an interface editor program,
X_MAKE.EXE, is included. It allows the edition of a complete user
interface, and the automatic generation of an skeleton program in Pascal or
C, that is a fully functional program that the user can edit and complete.
TYPICAL PROGRAM STRUCTURE
-------------------------
Below is the structure of a typical program using the interface:
- Program header:
- Declaration of global variables and interface "objects".
- Normal subroutines.
- Subroutines called from the interface objects ("callbacks").
- Main program:
- Normal initialization.
- Interface initialization: call to "xv_init".
- Creation and initialization of the interface objects: calls to
"xv_create" followed by direct initialization of the object parameters.
- Passing of control to the interface "notifier": call to "xv_main_loop".
- Normal termination.
INTERFACE OBJECTS
-----------------
The user interface is composed of "objects". Note that the interface was
not programmed with "object-oriented" specific techniques, but some ideas
are used.
There are eight types of predefined objects, listed below. Their names
are the parameters to be passed to the "xv_create" procedure.
- "frame": Base windows, where the other objects are.
- "button": Command buttons.
- "textfield": Input fields for text and numerical values, with edition.
- "setting": Input fields for logical values (choices).
- "message": Messages or icons in the windows.
- "canvas": Graphical output subwindows.
- "tty": Text output subwindows.
- "menu": Pop-up menus.
Other types of objects can be programmed, if necessary, by adding the
desired functionality to "canvas" objects through their "callback"
routines. See the example program ROTOR.PAS.
EVENT-ORIENTED PROGRAMMING
--------------------------
The interface is intended to be used in an event-oriented program. The
basic ideas are:
The program does not follow a predefined fluxogram, but is commanded by
the user, that generates "events" by acting on the objects in the windows,
what causes calls to the "callback" routines, where the program functional
code is located.
Any "callback" subroutine can be called at any moment. In its initial
code, it can be necessary for the routine to check the program status to
determine what is to be done. The program status can be maintained in a set
of global logical variables, and/or in the "textfield", "setting", and
"menu" objects.
The "callback" routines have complete control of the machine while active.
They can open or close windows using "open_window" and "close_window",
draw in "canvas" objects using the normal graphical functions, print
messages in "tty" (using "ttysw_output") or "message" objects (using
"xv_set"), or anything else that does not corrupt the interface structures.
The user is never prompted for information in a way that blocks the
program execution (it is possible, if necessary, through windows with
exclusive access (see the file EXCLUSIV.INC), but not recommended). The
procedure for getting information from the user is to open a window with
items to filled. "Callback" routines associated with the window objects
update the program status and continue the execution, when and if the user
commands.
The program never reads the keyboard or mouse directly (it is possible,
using the normal functions and the MICKEY module functions, but also not
recommended). All the inputs from the user are received as events and actions
on the objects.
The objects call "callback" routines by three mechanisms, associated with
the object attributes:
"notify_handler": A "callback" routine, called when:
- "frame": The window is closed.
- "texfield": The return key is pressed, at the end of an edition.
- "canvas": The window is redrawn, on the opening and resizing of the
window.
- Other objects: The left mouse button is pressed over the object.
"event_handler": A "callback" routine, called when the state of the mouse
changes over the object, or when a key is pressed, with the mouse pointer
over the object.
"menu_name": Name of a "menu", opened with the right mouse button pressed
over the object. The menus normally have an associated "notify handler",
called when a selection is done. It is also possible to open a menu
programatically, using the "menu_show" procedure. The items of a menu can
have an associated "item_submenu" (name of another menu),also opened with
the right mouse button. The same is valid for submenus of any order. The
left mouse button always cause the selection of the present item, even if
there are submenus. The central mouse button (or both right and left
buttons simultaneously) cause the dismiss of menus without a call to the
menu "notify_handler".
The "callback" routines have always the same structure. They are far
procedures receiving a single argument, that is the calling object pointer.
Using this pointer, the parameters of the calling object can be accessed.
EVENTS
------
The "event_handler" routines can read the event that caused the call in
the global variable "ie_code". Its meanings are:
- Mouse events: "ie_code" contains:
LOC_MOVE: Movement.
LOC_DRAG: Movement with some button pressed.
MS_LEFT: Left button pressed.
MS_MIDDLE: Central button pressed.
MS_RIGHT: Right button pressed.
The state of the mouse buttons (as returned by the DOS interrupt 33) is in
the global variable "ie_shiftcode".
The event names above are predefined constants. In the general case for
button events, "ie_code"=1000+10*<buttons before>+<buttons after>.
The mouse position, relative to the object upper left corner, is in the
global variables "ie_locx" and "ie_locy". The absolute mouse position is also
available in the variables "mousex" and "mousey", defined in the MICKEY
module.
- Keyboard events: "ie_code" contains the ASCII code of the pressed key. In
the case of keys with extended codes, "ie_code" contains 2000+2nd code.
With the mouse emulator in operation (see the MOUSE DRIVER section), events
that are used by the emulator are not generated, unless the ScrollLock key is
active, what returns the keyboard to normal operation.
Some events interpreted by the interface are not passed to the
"event_handlers". Only the "canvas" objects receive all the events. In any
way, there is no much sense in detecting events over other objects.
WINDOWS
-------
There is always an active window, which "f